Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for function-based velocity advection on constant and higher order discontinuous variables #12

Merged
merged 5 commits into from
May 13, 2024

Conversation

smpark7
Copy link
Contributor

@smpark7 smpark7 commented May 8, 2024

Description

PostprocessorVelocityFunctionInflowBC and VelocityFunctionConservativeAdvection are similar to PostprocessorInflowBC and ConservativeAdvection, but with function-based velocity profiles.

PostprocessorPenaltyDirichletBC is similar to PenaltyDirichletBC, but with a postprocessor to set the boundary value.

PostprocessorVelocityFunctionInflowBC is required to fix arfc/moltres#183.

VelocityFunctionConservativeAdvection and PostprocessorPenaltyDirichletBC are required to fix arfc/moltres#265.

Changes

  • Add PostprocessorVelocityFunctionInflowBC
  • Add VelocityFunctionConservativeAdvection
  • Add PostprocessorPenaltyDirichletBC

@smpark7 smpark7 changed the title Add PostprocessorVelocityFunctionInflowBC and VelocityFunctionConservativeAdvection Add support for function-based velocity advection on constant and higher order discontinuous variables May 10, 2024
@smpark7 smpark7 self-assigned this May 10, 2024
Copy link
Contributor

@LukeSeifert LukeSeifert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I only had some questions on the documentation and the variable names. I have noticed when looking at MOOSE source code it uses really short variable names like _t, why is that?

@@ -0,0 +1,23 @@
# PostprocessorVelocityFunctionInflowBC

!alert construction title=Undocumented Class
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is documentation going to be added in a future PR?

@@ -0,0 +1,23 @@
# VelocityFunctionConservativeAdvection

!alert construction title=Undocumented Class
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Real
PostprocessorPenaltyDirichletBC::computeQpResidual()
{
return _p * _test[_i][_qp] * (-_pp + _u[_qp]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These variable names don't seem great to me, how come something longer isn't used?

@smpark7
Copy link
Contributor Author

smpark7 commented May 10, 2024

@LukeSeifert Thanks for the quick review! I added documentation to the markdown files and I renamed the variables to _penalty and _postprocessor. I think the MOOSE team used to be more lax about variables names. To be fair the names usually quite obvious (e.g. _t usually means time). As the framework grew over the years, naming conflicts have cropped up. However, it can be difficult to "rectify" some of the names without impacting a large number of users and MOOSE-based apps downstream.

Feel free to merge if you approve!

Copy link
Contributor

@LukeSeifert LukeSeifert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@LukeSeifert LukeSeifert merged commit cb4101d into arfc:master May 13, 2024
@cticenhour
Copy link
Contributor

I think the MOOSE team used to be more lax about variables names.

@LukeSeifert @smpark7 I have no doubt that we might have been a bit more lax in the past. 😄 The decision on _t was a decent bit before my time though. I would like to think that short-named spatial and temporal variables that get inherited (like _t) come from how one naturally writes a simple function down on paper (i.e., f(x,y,z,t) = 5xt). I should ask one day. For my code, I try to make my object variable names longer so as to be more descriptive. There are almost certainly many places we could fix up in MOOSE and many apps though 😆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants